@fredden Thanks for the PR. I can't say anything about whether it will be accepted or not, but can give you some feedback in general terms, but in the end, it's @gsherwood's decision.

• Most of the extensions you now listed in require are only needed for specific features, not for the application in general.
  As a matter of course, extensions which ship with PHP and can not be disabled do not need to be listed.
  The five extensions you've now added all ship with PHP and are all enabled by default (though most can be disabled).
  In most cases, the uses of those extensions will be conditional on the extension being available, which means the extension is not actually required (though could be added to suggest with a hint as to which functionality requires the extension).
  It could be that in one or two cases, the "conditional use" has fallen through the cracks, in which case, that should be fixed (instead).
• The autoload sections are redundant as PHPCS handles this in the application bootstrap.
  Additionally, a PSR4 autoload section for the src directory can actually break the PHPCS translation between classes and sniff names, which is needed for the correct handling of (custom) rulesets.
  Furthermore, PHPCS also supports PHIVE, PEAR and git clone installs, so relying on Composer for the autoloading would be wrong and unstable.
• In my experience, the general tendency for PHPCS has been to have a minimal set of dependencies, even dev dependencies, so not sure adding a new tool will be welcome.

Sorry to be a party-pooper.

It could be that in one or two cases, the "conditional use" has fallen through the cracks, in which case, that should be fixed (instead).

Would it be helpful for me to open pull requests for each of the identified extensions, and add a "conditional use" check around these? We could then move these extensions from the require section to suggest.